Skip to content

boot: zephyr: kconfig: Default to swap using offset #2266

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 18, 2025

Conversation

nordicjm
Copy link
Collaborator

Defaults to the new swap using offset mode

@nordicjm nordicjm requested a review from de-nordic as a code owner April 17, 2025 07:53
@@ -397,14 +397,14 @@ config BOOT_VALIDATE_SLOT0_ONCE

config BOOT_PREFER_SWAP_OFFSET
bool "Prefer the newer swap offset algorithm"
default y if SOC_FAMILY_NORDIC_NRF
Copy link
Contributor

@butok butok Apr 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make it default for all platforms?
By adding: default y if !$(dt_nodelabel_enabled,scratch_partition)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not been made the default for all platforms due to the sector size requirements, if a device has equal sizes for slot 0 and slot 1 then it will work (but is not ideal) but if it has the swap using move ideal setup of slot 0 being larger than slot 1, it will fail, so has been left as swap using move for default for now

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a device has equal sizes for slot 0 and slot 1 then it will work (but is not ideal)

Using optimized slot sizes is broken with the latest mcuboot: zephyrproject-rtos/zephyr#88850
It seems, I need to switch to equal slot sizes (at least for NXP) to make it work for all modes, even if it's not optimal.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That has been fixed efa3039 but has not been pulled into zephyr yet

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That has been fixed efa3039 but has not been pulled into zephyr yet

Great! Thank you.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

having a look at frdm_ke17z it looks like it should work, would be just under 2K for swap status fields so not sure why it throws an error, would suggest enabling debug logs for MCUboot and seeing what is printed, then setting the number of sectors for each slot to the same and seeing what the non-optimal message says

Copy link
Contributor

@butok butok Apr 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

having a look at frdm_ke17z it looks like it should work, would be just under 2K for swap status fields so not sure why it throws an error, would suggest enabling debug logs for MCUboot and seeing what is printed, then setting the number of sectors for each slot to the same and seeing what the non-optimal message says

For example for frdm_mcxw71, it has Flash total size 1M , 8KB erase and 16B write. Partitioned to:

&flash {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;
		/* The MCUBoot swap-move algorithm uses the last 2 sectors
		 * of the primary slot0 for swap status and move.
		 */
		boot_partition: partition@0 {
			reg = <0x0 DT_SIZE_K(64)>;
		};
		slot0_partition: partition@10000 {
			reg = <0x10000 (DT_SIZE_K(416) + DT_SIZE_K(16))>;
		};
		slot1_partition: partition@7C000 {
			reg = <0x7C000 DT_SIZE_K(416)>;
		};
		storage_partition: partition@E4000 {
			reg = <0xE4000 DT_SIZE_K(112)>;
		};
	};
};

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW: Is see another PR fix is coming "boot: bootutil: Fix max image size computation for swap-move and swap-offset" #2283

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All NXP boards were switched to equal size partitions.
May NXP be switched to SWAP_OFFSET too? Or is it still experimental and better to wait until it becomes the default mode for all?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll cobble together a php script in a bit to check slot0 and slot1 sizes for all boards and see if there's any that are not equal and if so message the maintainers and ask about them because would like to set it as default for all

nordicjm added 2 commits July 18, 2025 07:44
To prevent breakage when the default mode changes to swap using
offset, any board that is current set up to have more sectors in
slot0 has been excluded from the move

Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Defaults to the new swap using offset mode, excluding stm32 as
these devices are already aligned to swap using move with extra
sectors in slot0

Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
@nordicjm nordicjm changed the title boot: zephyr: kconfig: Default to swap using offset for nRF devices boot: zephyr: kconfig: Default to swap using offset Jul 18, 2025
@nordicjm nordicjm requested a review from butok July 18, 2025 06:51
@nordicjm nordicjm merged commit b9ba257 into mcu-tools:main Jul 18, 2025
58 checks passed
@butok
Copy link
Contributor

butok commented Jul 18, 2025

Thank you.
Do we need additional configuration changes for the Zephyr McuBoot Sysbuild?

@nordicjm
Copy link
Collaborator Author

Thank you. Do we need additional configuration changes for the Zephyr McuBoot Sysbuild?

yes, will update that in a future PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: zephyr Affects the Zephyr port
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants